Functional verification is the process that ensures conformance of a hardware or software design to its specification. The verification process includes defining a test plan for a set of events that the verification team would like to observe during the verification process. The test plan is usually implemented using random stimuli generators that produce stimuli in the form of test cases.
The stimuli is fed to a simulator that runs the tests on the design under verification. Coverage tools then detect the occurrence of events in the test plan, and report on the progress of the test plan. In recent years, stimuli generation technology has shifted towards constraint-based modeling of the generation task, coupled with stimuli generation schemes driven by solving constraint satisfaction problems (CSPs).
The validity and quality of the stimuli, along with test specification requirements, are naturally modeled through constraints. For a CSP to drive stimuli generation, the stimuli, or its building blocks, are modeled as constraint networks. A random stimuli generator can, therefore, be viewed as a special purpose CSP solver.
A CSP is defined by a set of variables and constraints. Each variable has a set of values as a domain. Each constraint is expressed as a relation, defined over some subset of the variables, denoting valid combinations of their values. A solution to the CSP is found based on an assignment of a single value to each variable that satisfies all of the defined constraints. The constraints can be defined as hard or soft constraints. For a solution to be valid, all hard constraints must be satisfied, but a soft constraint may or may not be satisfied.
Soft constraints can thus be used to relax certain system requirements that may not be “necessary” to a solution, thereby allowing for generations of a higher quality solution set by the CSP solver. Some solutions in the set satisfy all constraints (hard or soft), while other solutions satisfy all the hard constraints but not all the soft constraints. As such, instead of defining all constraints as hard constraint, a user can define certain constraints as soft constraint to enhance the quality of the solutions generated.
To enhance the quality of the solutions, a CSP solver is configured to satisfy as many soft constraints as possible, according to a certain hierarchy or success rate. That is, the solution process can be biased towards higher quality solutions that meet one or more probabilistic requests. A probabilistic request (hereafter “PR”) can be submitted by a user to define that one or more soft constraints are to be satisfied in a predefined percentage of the generated solutions. Thus, the PRs ensures that the randomness in not lost in the solution process.
Advantageously, defining a PR allows for a larger variety of solutions, since it allows the user to soften the requirements from the generated stimuli. Unfortunately, however, it is usually extremely difficult to identify whether the generated stimuli conforms to a PR. This, in large part, is attributed to the intricate relationship between the PRs and the soft constraints.
Systems and methods are needed to address the above-mentioned shortcomings by giving the user an indication of the solution's compliance with the user defined PRs.